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I, RICHARD M. ONYON, declare that: 

1. I am an inventor of the invention described and claimed in the above-identified patent 
application. I am currently the Chief Executive Officer of fusionOne, Inc., assignee of the instant 
application, and am a co-founder of the company. I have reviewed the pending application as stated 
in my Declaration for Patent Application and the pending claims 49 - 75, which are set forth in the 
RESPONSE A TO OFFICE ACTION ("RESPONSE A") accompanying this DECLARATION. I 
have also reviewed U.S. Patent No. 6,295,541 having a filing date of June 7, 1999, and claiming 
priority to United States Provisional Application Ser. No. 60/069,73 1 , filed Dec. 16,1 997, Ser. No. 
60/094,972, filed Jul. 31, 1998, and Ser. No. 60/094,824, filed Jul. 31, 1998. 

2. I understand that this Declaration will be filed in the United States Patent and Trademark 
Office in order to provide factual evidence showing that the invention claimed in the present 
.application was completed prior to the date of December 16, 1997. 
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3 . The facts set forth hereinafter to establish that the claimed invention was completed prior to 
December 16, 1997 all relate to acts which occurred and were carried out within the United States. 

4. In January of 1997, I began working for a company called Cachelink Corporation in 
Westboro, Massachusetts. Cachelink later changed its name to Mango Software. When I began 
working at Mango Software, the company was focused on developing a system for "pooling" the 
disk and memory resources of computers across a TCP/IP network. The product under development 
embodying this concept was called Medley97. Medley97 was a storage-oriented, distributed 
network operating system which pooled the resources of network-attached machines to create a 
single, virtual server. 

5. I was hired at Mango Software as the Vice President of Sales and Marketing. My job was to 
transform Mango Software from an engineering only company into an operating company with 
sales and marketing functions. I was also charged with taking the Medley97 product to market. 

6. Before the launch of Medley 97, and well prior to December of 1 997, 1 had a discussion with 
one of my former technical employees, Leighton Ridgard, about the technical merits of Medley 97. 
Our discussions included how one could implement a system for keeping files current across a 
number of machines which were not concurrently connected. Essentially, what I had envisioned was 
a synchronization solution, which I personally needed based upon my unrelenting travel schedule 
and the fact that I owned several computers. With the sync system I envisioned, if my home PC was 
always in sync with my office PC's files, I would not have to transport my work home at night. Or, 
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if I was going on a business trip, I could simply take my laptop computer without concern for 
whether or not its contents were completely current. For example, even if I was in Japan, I could 
plug into the Internet and trust that my laptop's content would soon match my office PC's. While 
Mango focused on concurrent file access for groups of people across the Internet, I believed there 
was a bigger opportunity in keeping files "in sync" across multiple computers for one person. 

7. The core concept conceived of during the conversation between myself and Mr. Ridgard 
described above, and which evolved over the months that followed, was originally focused on 
keeping data files, such as word processing, presentation and spreadsheet files, in sync. Syncing 
data files is a function which even today is not performed by a number of sync solutions. In general, 
I needed a system to keeping files "concurrent" across a series of computers which were not located 
physically near each other in a way that was Internet centric (using, for example, TCP/IP), very 
efficient (so that even low bandwidth connections could be used to sync a PC) and asynchronous 
(since all PCs were never likely to be connected at the same time). At that time, all sync products of 
which I was aware were local in nature, and reconciled differences by comparing information on the 
two devices to be synchronized at the same time. Such a comparison requires a relatively high speed 
data connection, such as a physical cable between the devices. Our concept envisioned that a large 
file belonging to one user could be maintained in synchronization among two or more PC's on the 
opposite ends of the country through a connection to the Internet because only a tiny "piece" of the 
file actually needed to be moved across the Internet when a change was detected. 

8. In the months following the initial conception of my file sync idea, and prior to December, 
1997, 1 began discussing the file sync concept with Sally Winship (now Sally Winship-Comollo, 
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Vice President of Corporate Communications for fusionOne, Inc.), who was at that time Mango's 
press relations manager. During these discussions, Ms. Winship-Comollo and I also began 
discussing my desire to build a new company again. We agreed that the file sync product was a 
good idea and worthy of pursuit in a new business venture. My discussions with Ms. Winship- 
Comollo and Mr. Ridgard continued into the fall and winter of 1997/1998 through construction of 
the prototypes, and intensified as technical issues with Medly97 led to turmoil at Mango Software. 

9. Prior to December 1 997 Leighton Ridgard and I discussed how to synchronize Outlook data 
between two PCs. Initially we considered syncing Outlook's entire PST from one place to another, 
following the idea of syncing a data file. While this would have worked it did not takes us long to 
realize that Outlook's PST was large and sometimes only a small thing changed such as marking an 
email as read. Leighton knew of the existence of technologies to compute and efficiently generate 
the binary difference between two files. Xdelta was one such technology. We quickly decided that 
we would use binary differencing technology to generate a small difference between the PST files 
and transmit that difference during the sync. We began investigating acquiring binary differencing 
technology through purchase or writing it ourselves. 

10. It did not take us long to further conclude that syncing PST with binary differences would 
only work when one wanted both machines to be identical. We quickly realized that in order to have 
one machine contain a subset of the data found on another machine we would have to parse the PSTs 
and extract only the required data. We decided at this point to use Binary differencing would work 
for files. Outlook and other PIM content would need a different methodology. 
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1 1 . Well prior to December 1 997, 1 had several meetings with Ms. Winship-Comollo where we 
flushed out further details of the file sync system design. During at least one of these meetings, 
using the white board in her office, I drew block diagrams of the "store and forward" system. 
According to my original conception of a store and forward system, when a change is made to file 
data on a first computer, those changes would be recorded and transported via a network to be 
stored on an FTP server. At some later point in time, whether or not the first computer was coupled 
to the network, those changes could be forwarded to a second computer. In this conception, I 
envisioned some triggering event to forward and retrieve changes to and from the sync server. 
These drawings were erased from her whiteboard at the conclusion of our meeting and no copies of 
these drawings were made. 

12. During our discussions regarding transmitting only that piece of the file which had changed, 
we realized that the method of creating and recording changes to only that portion of the data which 
had changed meant we needed some representation of the data file prior to the change. This need 
for a known state of a data file evolved into the so-called application object store or "AOS". The 
AOS is essentially a known state of a user's data as of the last time our system checks to determine 
whether any changes are made to the user's data. The construction of the prototype of the AOS 
application began prior to December of 1997, with numerous substantive technical discussions 
regarding the application taking place prior to October 1997. 

13. It was at this point, again well prior to December 1 997, that we invented our change log and 
AOS technology. It was decided that we would need to extract from the PIM each item individually 
and transmit that item efficiently across to the other device. In order to do this we would need to 
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compute the difference between the PIM data now and the PIM data at the time of last sync. Having 
already spent time examining delta technology (which we decided we would use for unstructured 
data such as files) we then created what we called "Structured Delta". Two systems of discovering 
the "difference" between the PIM now and when we last synced it was created. One was to monitor 
the PIM for user activity (changing, records, adding records etc.). Another was to store a copy of the 
PIM data at the end of the sync (in our AOS) and then to compare the stored copy with the PIM copy 
and determine the differences. Regardless of the method used to compute the differences, we created 
a system of representing the differences by using a set of operations followed by the data used by 
that operation. In other words, we created a log of activity (also called a "change log" or "data 
package") that contained instructions (such as add, delete, modify, rename, and move) along with 
the relevant data. 

1 4. When creating the change log, we realized we should provide information in a header for the 
change log to describe the contents of the change log. At this point in time it was decided that the 
header should contain a signature, the identity of the generating device, the date, the PIM used, 
version schema in use etc. 

15. Still well prior to December 1997, we realized that someone who syncs frequently would 
generate a lot of these change logs. At this time, we thought they would be stored on an FTP site, 
and storage space was a consideration. We further discovered that even after items were deleted their 
previous existence would be evident in the old change logs. In order to more efficiently manage the 
users space it was decided that a process could be developed to combine the change logs. We called 
this process "log rolling" at the time. Initially we thought about running this process on a back-end 
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server without even involving the user. Such a process would apply successive change logs to each 
other and combine changes and deletes etc. to produce a minimal set of resultant changes collapsed 
into ideally one change log. During these discussions we decided that even if not done behind the 
scenes on the server, this feature would be equally valuable if implemented on the client. We later 
decided to called server-side log rolling "Base rolling" and left the term "log rolling" for use in 
describing client-side rolling. 

1 6. Our discussions on finalizing the structure proceeded rapidly and within two weeks of when 
we started we had a thorough understanding of what we wanted to build. 

17. After this initial series of technical discussions, I asked Mr. Ridgard to construct a prototype of 
the system based on these discussions. I recall this construction beginning prior to December of 1997 
and being completed in or about February 1998. I am aware that his recollection is that he began later. 
Despite my eagerness to get started, Leighton could not begin until then because he was employed 
elsewhere and had other responsibilities. In the interest of time (and because he was the only person 
working on this) it was decided to produce a proof of concept prototype which synced the entire PST 
from one device to the other. Although this was certainly not the implementation upon which we had 
decided, it was sufficient as a proof of concept. In the spring of 1 998 two other engineers joined him and 
we produced the second prototype which implemented an early version of our change log technology. 

18. Throughout our development of our system, we worked diligently to reduce the invention to 
practice. This included the creation of at least three (3) prototypes throughout the process of hiring 
engineers and gaining funding to complete development of the system. 
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1 9. I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the like so made are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that 
such willful false statements may jeopardize the validity of the application or any patent issued 
thereon. 




'nyon 
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